-
-
Notifications
You must be signed in to change notification settings - Fork 33.5k
vm: make vm.Module.evaluate() conditionally synchronous #60205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #60205 +/- ##
==========================================
+ Coverage 88.53% 88.55% +0.01%
==========================================
Files 704 704
Lines 208087 208151 +64
Branches 40010 40013 +3
==========================================
+ Hits 184239 184322 +83
+ Misses 15866 15863 -3
+ Partials 7982 7966 -16
🚀 New features to boost your workflow:
|
Added a benchmark for source text modules - there are some performance improvements by removing the async-await:
|
63566f6
to
a482e51
Compare
- Make sure that the vm.Module.evaluate() method is conditionally synchronous based on the specification. Previously, the returned promise is unconditionally pending (even for synthetic modules and source text modules without top-level await) instead of immediately fulfilled, making it harder to debug as it deviates from the specified behavior. - Clarify the synchronicity of this method in the documentation - Add more tests for the synchronicity of this method.
a482e51
to
d308c89
Compare
Updated the evaluate implementation so that it keeps rejecting for loader errors yet still returns an immediately fulfilled promise for the actual evaluation. The perf numbers are still similar:
|
Opened a separate issue about the rejection #60242 |
case it will either do nothing if the initial evaluation ended in success | ||
(`module.status` is `'evaluated'`) or it will re-throw the exception that the | ||
initial evaluation resulted in (`module.status` is `'errored'`). | ||
If the module is a `vm.SourceTextModule`,`evaluate()` must be called after the module has been at least linked; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The status check requires the module to be instantiated.
node/lib/internal/vm/module.js
Lines 224 to 226 in 170848b
if (status !== kInstantiated && | |
status !== kEvaluated && | |
status !== kErrored) { |
If the module is a `vm.SourceTextModule`,`evaluate()` must be called after the module has been at least linked; | |
If the module is a `vm.SourceTextModule`, `evaluate()` must be called after the module has been instantiated; |
fulfilled _synchronously_ after the module and all its dependencies have been evaluated. | ||
1. If the evaluation succeeds, the promise will be _synchronously_ resolved to `undefined`. | ||
2. If the evaluation results in an exception, the promise will be _synchronously_ rejected with the exception | ||
that causes the evaluation to fail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth directing users to infer module.error
, instead of inspecting the promise.
that causes the evaluation to fail. | |
`module.error` that causes the evaluation to fail and . |
This patch:
Refs: #59656
Refs: #37648